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someone else's password. 


in an system 


However, 
interconnected by unencrypted data 
communications radios (i.e., a party- 
line), the login process using passwords 
is ineffectiv becaus any casual 
observer can, by monitoring the radio 
channel, determin any other user's 
password. Also, once the user is logged 
in, there is nothing to prevent someone 
else from masquerading as the authorized 
user. 


open 


Offered below is an alternative 
approach to passwords for open, 
unencrypted, communications with a host. 
The method assumes that the user wants 
only to give commands to the host, not to 
do file transfers. However, with a few 
embellishments, the system could be 
expanded to include file transfers. The 
system would be as follows. 


Proposal 


When the host gives a prompt to the 

telling the user that she or he may 
the prompt will 
(RN) as part of 


user, 
send it the next command, 
include a random number 
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Abstract the prompt. Each time a prompt is 
transmitted, a new random number is 
This paper presents an idea for included. The host then encrypts the 
verifying that a user within a party-line last RN transmitted using the key-for- 
network is who he or she claims to be. the-day (KEY) previously agreed to by 
The idea assumes that the channel is a both the authorized user and the host; I 
party-line and that potential intruders will call this "Encrypted RN" the "“ERN". 
will monitor authorized communications The host would then place the ERN in 
and may attempt to masquerade as storage for safe keeping and quick 
authorized users. No attempt is made to access. The user, on receipt of the new 
encrypt the authorized user's data _ for RN, would also encrypt it using the KEY 
transmission over the party-line. (obtaining the same ERN if the KEYs are 
the same) and would save it, too, ina 
handy place. When the user wanted to 
Introduction issue a command to the host, it would 
give the command, as the host requires, 
Verification of a users identity to but it would include the latest 
a host, historically, has been a major calculated  ERN. When the host receives 
problem. At the lowest level of the command line, it compares the ERN 
protection, many hosts require the user received from the user with the ERN it 
to "login" before he or she can make use calculated from the last RN transmitted 
of any of the system's protected as part of the prompt. If they match, 
resources. Login procedures, making use the host assumes that the user knows’ the 
of passwords, are useful on most systems correct key. Thus, by returning the 
because it is assumed that a potential expected ERN, the user has proved to the 
intruder will not be able to monitor host that he or she is authorized to 

easily the login process and determine access the system. 


Vulnerabilities 


This scheme is not without its 
problems. Because the key is changed 
only once a day, the range of numbers 


used for RNs must be large to ensure that 
RNS are not repeated during the 24-hour 


period. Also, the range of RNS must be 
large enough to make the probability of 
either determining the KEY or "guessing" 


the ERN sufficiently small. A RN of 64 
bits should be large enough to overcome 
this problem. Another important 
consideration is the quality of the 
encryption technique. For Amateur Radio 
applications the DEA (that's Data 
Encryption Algorithm -- the software 
approach to DES) should be suitably 
strong. 


vulnerable to’ the 
who monitors the 
and, 


This system is 
sophisticated intruder 
channel to determine the user's ERN 


before the user's packet transmission to 
the host is complete, the intruder jams 
the channel to block the user's packet 
from reaching the host. Next, the 


intruder sends his or her own packet with 
an illicit command and the ERN received 


from the user. This scenario can be 
avoided by having the user transmit the 
ERN as the last item contained in the 
data segment of the packet. 


Implementation 


How might a system such as this be 
implemented? One way would be to include 
the host's 64 bit RN in the command 
prompt using hex notation and prefacing 
the RN with a special character sequence, 
perhaps composed of an unlikely sequence 
of punctuation characters so that a 
computer could identify it. Here's an 
xampl wher the normal host system 
prompt is the word "yes?" and is prefaced 
by the RN. 


://:0FEB23178ED83A9A yes? 


The user% terminal emulation program 
(or, possibly, packet controller (TNC)) 
would assume that a new RN follows’ the 
scap sequence ://: and that it is in 
hex notation. It would, using the key- 
for-the-day, encrypt the RN to create an 
ERN to be saved for future use. When the 
user gives a command to the host that 
requires the transmission of the latest 
ERN, the operator would tell the terminal 


program (or, again, the TNC) to 
substitute the ERN in place of an escape 
sequence. When the terminal program sees 


the escape sequence (such as ##), it 
would substitute the ERN (with a 
different preface than the RN) before 
transmission. An example of a command 
line with the escape sequence might be: 


COFFEEPOT ON ## 
The terminal program would substitute the 


scap sequenc (##) with the last 
calculated ERN. An example: 


COFFEEPOT ON /::/07EAF832B1A9E9A2 
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A method such as this would add about 20 
characters 'of overhead to each packet 


that contained a command for a 
"protected" host. However, if the 
protection is adequate for the 


environment, that appears to be a small 


price to pay. 


Extensions 


Again, although the idea presented 
here is simple, it should prove adequate 
protection against the more-than-average 
hostile user who might try to disrupt 
authorized communications. Other 
extensions to improve its protection 
might include calculation of a checksum 
or a more complex data reduction 
technique across all data within the 


frame and use that as another dimension 
for encryption to create the ERN[1]. 
Certainly what has been presented here is 
only a first step. I encourage others to 
pursue this and additional methods of 
providing authentication within an open, 
party-line, network. 


Notes 
[1] Private communication with Mr. 


Philip Karn, ka9q, Bell 
Communications Research. 
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